请教高人SLED对FAT32下文件能建能删却不能覆盖保存的问题
系统：SUSE Linux Enterprise Desktop 10 SP1启动时自动挂载格式为FAT32的F盘到/home/windows/F下，可以在F盘上创建文件，
用gedit编辑的新文件也能保存到F盘上，但如果是修改后再点保存，则报错说Could not
save the file "/windows/F/filename.c"。选择另存为新的文件名则可以保存，也就是
说不能覆盖原来的文件。删除可以。
能够用gcc(g++)编译F盘上的C(C++)文件并得到可执行程序，比如为“filename”，但
如果执行“./filename”，则会出现“bash: ./filename: Permission denied”的错误。而
把文件filename放到linux所在分区用户目录下则可以正常执行。切换到root权限也一
样，另外把文件放到挂载到/home/media/disk下的FAT32格式的优盘里也是如此。
etc下的fstab文件内容为：
------------------------------------------------------------------------------
/dev/disk/by-id/ata-Hitachi_HTS541680J9AT00_SB0201SGGKPAKB-part2 /
reiserfs acl,user_xattr 1 1
/dev/disk/by-id/ata-Hitachi_HTS541680J9AT00_SB0201SGGKPAKB-part1 /windows/C
ntfs ro,users,gid=users,umask=0002,nls=utf8 0 0
/dev/disk/by-id/ata-Hitachi_HTS541680J9AT00_SB0201SGGKPAKB-part5 /windows/D
ntfs ro,users,gid=users,umask=0002,nls=utf8 0 0
/dev/disk/by-id/ata-Hitachi_HTS541680J9AT00_SB0201SGGKPAKB-part6 /windows/E
ntfs ro,users,gid=users,umask=0002,nls=utf8 0 0
/dev/disk/by-id/ata-Hitachi_HTS541680J9AT00_SB0201SGGKPAKB-part7 /windows/F
vfat users,gid=users,umask=0002,utf8=true 0 0
/dev/disk/by-id/ata-Hitachi_HTS541680J9AT00_SB0201SGGKPAKB-part8 /windows/G
ntfs ro,users,gid=users,umask=0002,nls=utf8 0 0
/dev/disk/by-id/ata-Hitachi_HTS541680J9AT00_SB0201SGGKPAKB-part9 /windows/H
ntfs ro,users,gid=users,umask=0002,nls=utf8 0 0
/dev/disk/by-id/ata-Hitachi_HTS541680J9AT00_SB0201SGGKPAKB-part3 swap
swap defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
------------------------------------------------------------------------------
将F盘的umask改成000也一样。
问了很早玩linux的一个同学，他说没见过这问题，所以只好发到版上请教高高手
了。先谢谢了！！ 在[url=https://bugs.launchpad.net/gedit/+bug/69184]https://bugs.launchpad.net/gedit/+bug/69184[/url]看到类似的问题，貌似Vim没事，没试过，可是gcc不能写就郁闷了。
下面这个方法不知行不行
[color=#003399]Constantine Evans[/color] wrote on 2006-10-31: [url=https://bugs.launchpad.net/gedit/+bug/69184/comments/2][color=#003399](permalink) [/color][/url]
[font=monospace]I've figured out the problem, and added a description of it to the upstream bug. For now, you can get around the issue by mounting with the option umask=(YOUR_USER_NUMBER) instead of umask=000 (probably umask=1000).
就是把000用用户ID代咯。
[/font] 对！在vfat那行加一个umask=0试试，应该能解决。 便是对原来文件没有写操作,不建议把umask=0,不安全
页:
[1]