Folders on Syntology NAS that contain an accent character are shown shortened on my Windows 7 machine.
i.e
Folder Béla Fleck and The Flecktones is shown in Windows as W:\Music\B39PEX~5
Why is this so, and can I change this so it doesnt happen
If I'm not mistaken this is most certainly Samba server issue. Samba is file accessing, sharing and exchanging protocol. And in most times it doesn't like UTF-8 encoded file names. If you have some old version of Samba installed on your NAS, this could be the answer. Plus: if your NAS runs under Linux and you access it from Windows, an additional problems takes place, as any Windows' Samba client is so poorly written that is has many issues and problems, which you won't find in Samba clients for other systems.
In general, solution is only one: Stop using non-standard characters in your file names and folders. I wasted so many hours on finding similar solution and ended up with a big rename solution to get rid of such "bulky" names.
Related
Situation: I'm on a stand-alone development computer running Windows 7. Not connected to any Windows Server. Would like to test a Window application's ability to use UNC paths. Will be transferred later to a Linux server (not at my location), hence the desire to use a cross-platform path mechanism (UNC) (//servername/sharename), rather than a Window's mapped drive (X:\foldername).
The application is Autodesk Maya 2014. A project's main file contains many references to other files. These file references can be relative paths ("subfolder/filename.ext"), absolute paths ("H:/projects/this_project/subfolder/filename.ext"), or UNC paths ("//servername/projects/.." or "servername/assets/..").
The app permits forward slashes, and maps those to the correct character on different OSes. Wherever possible, I use relative paths.
But I have a situation where a plug-in is not correctly working with relative paths, so I have resorted to using some absolute paths. It has been requested that I change these from the current mapped drive form, to UNC paths. REASON: the data will be transferred to a render farm, running Linux. A Linux version of the app will be used. (So my question isn't about accessing Linux files from my Windows box; it is about setting up all the data so that when everything is moved to the render farm, it will still run.)
Due to the combination of plug-ins and features we are using in Maya, I am not 100% certain I can convert all paths to relative form. (Questions there for Maya forums.) So as a fallback, I need to test with UNC paths. Am asking what it would take to set this up on my Windows 7 PC, without actually connecting to a server computer. (Don't have Linux nor Windows Server set-up at my location.)
I don't normally do network-related programming, nor server programming, so the various possible solutions are not familiar to me.
Googling suggests some basic techniques, that may or may not be relevant. Before I spend more time on this, want to know if I am going in the correct/easiest direction.
installing a local DNS server and editing its hosts file. Such as:
http://sourceforge.net/projects/acrylic/
http://sourceforge.net/projects/dhcp-dns-server/
.. but I don't have a domain name, I just have a (future) network computer name, so this is not relevant?
Editing LMHOSTS file
.. but this is just for mapping between a name and an IP address?
multiple NetBIOS names (OptionalNames)
Mentioned here:
http://www.mediamonkey.com/forum/viewtopic.php?t=51722&f=1
Which refers to:
https://serverfault.com/questions/23823/how-to-configure-windows-machine-to-allow-file-sharing-with-dns-alias
.. But that is talking about DNS, so is that relevant?
What I have succeeded in doing so far:
In Command Prompt (Run as Administrator):
net view \\localhost
or
net view \\mycomputernamehere
Lists shared folders on my PC. E.g. H:\temp Properties / Sharing, shared as "HTemp", which is listed.
So I think all I need to do is:
A. Share any folder with the desired name, e.g. "projects".
It will then be visible as "\\localhost\projects".
B. Convince Windows to use my local computer when I ask for "\\servername". I can then use "//servername/projects" in the app, which will ask Windows for "\\servername\projects", which then would be converted by Windows to "\\mycomputernamehere\projects".
... this (B) is the part I need help with. (3) above sounds like it is a solution. But to me it is rather arcane (editing the registry). Will it accomplish what I need? Is there an easy solution that doesn't involve registry editing?
And yes, somewhere along the way it dawned on me that the simplest solution is to rename my computer to "servername". I'll probably do that for this week.
But I'd still like to learn a way to alias my computer name, to fake a UNC path without actually renaming my computer. And without relying on a second computer acting as server.
This is a late answer, but for future reference:
Your suggestion of multiple NetBIOS names (OptionalNames) has worked for me to allow a Windows machine to accept UNC paths under other computer names.
For completess, you can combine this with adding the same alias's to the hosts file with the localhost ip 127.0.0.1 so IP traffic will always be redirected.
Maybe use the UNC version of localhost?
\\localhost\c$\tmp
Will map to your local c:\tmp folder.
I'm on Windows Vista Home Premium 64 bit OS. I use Apache Friends XAMPP server as my localhost. And I develop PHP, MySQL.
The problem is my local server is tolerant of case mistakes, especially in file/folder names.
When that running program on my server goes on linux servers, it's really a headache to locate and correct all the case errors.
So how can I make my local server case-sensitive as in linux servers?
No you can't. PHP file handling is dependant on the underlying O. Since Windows is a case-insensitive OS, it cannot handle files with a different case.
This won't change, as it will break a lot of applications. NTFS is a case-sensitive filesystem according to this KB article.
If you have an old PC doing nothing, install a Linux server on it. Or if you have enough resources (RAM), run a Virtual machine (with VirtualBox for example)
case-sensitivity is not due to the web server it self, but to the operating system.
Linux is case-sensitive not windows. As far as i know, you can't make windows case-sensitive.
but try yo keep all your folders/files lowercase, this will save you much headeach when moving to linux production server.
I have to start using CVS at my new company so that I can play nicely with the developers who are all *nix users. I happen to be a Windows Vista user and unfortunately do not have the ability to switch anytime soon. I am also not exactly a command line guru yet, so any simplified method is ideal for me.
I discovered TortoiseCVS today and it seems pretty straight forward, even though it says it is not directly supported on Vista, which worries me a little.
My questions:
Do you use CVS on Windows (Vista)?
What method do you use? (Tortoise CVS? Another option?)
Does your method get along well with repositories setup on/by *nix machines?
Any other advice for the noob? (Thanks)
I know many people who required a gentle introduction to cvs and ended up using WinCVS with no real difficulty. I know many others who are using the cvs client in Eclipse. This usage includes projects which are not otherwise managed by Eclipse. As for myself, I stick to the command-line myself because I feel the lack of GUI abstractions helps me to always understand exactly what CVS is doing. All three solutions work well on Vista, 32 and 64 bit. Our shop uses Mac, Linux, Solaris, and Windows, with the server on a Linux machine, and we never have any problems with compatibility.
There's one issue you should be aware of regardless of your choice of cvs client for cross-platform goodness, though. Most cvs clients convert between Unix newlines (on the server) and Windows newlines (on the client) by default. You should understand that this conversion is happening and be aware of the consequences.
This conversion will cause real problems if you try to commit a file with Unix newlines. So, you need to avoid, for example, copying files from a Unix repository to your Windows box, editing them, and committing them unless you've done the newline conversion. We had some real problems with this in my shop, and I instituted a strict policy that people should only communicate files between machines by committing them to CVS. Never, for example, by email, shared network directories, etc.
If your CVS repository has any binary files, some may not have been properly tagged as binary files. In *nix-only shop, nobody would notice, as the binary flag won't affect most binary files. But in a cross-platform shop, the binary flag routinely affects how cvs treats files, since it will disable any attempts at newline conversion. Typically, any file which was committed from a Unix box will be correctly represented in the repository, so you can fix the problem on the Windows end by merely changing the tag and re-updating. I.e.,
cvs admin -kb file
cvs update -A file
There are some other avenues you can take to interact with your *nix bretheren.
Install VirtualBox and a distribution of Linux so you can natively run the same toolset.
Install VirtualBox and a copy of Windows XP, which is known to work with TortoiseCVS.
You can find VMWare appliances pre-loaded with a linux distribution, which you can import into VMWare Player or VirtualBox. From there you just need to connect up to your shared drive the same way that they do.
Please note that CVS is no longer being maintained. You should really be moving to SVN, git, or some other version control system.
If you're using an IDE like Visual Studio or Eclipse, you should look for the appropriate plugin that integrates with your environment. Those might be better supported (though TortoiseCVS is likely just fine, even if the developers don't want to make any claims).
I was reading the post Installation file names in Windows Vista when I thought about Installation File Names. I'm a addicted software downloader, and frequently I've got installation names like "setup.exe" or "install.exe", that says nothing about the program to be installed.
I think that an installation file must be like:
Install[ProgramName][ProgramVersion][Platform].[exe|msi|etc]
or
[ProgramName][ProgramVersion][Platform].Setup.[exe|msi|etc]
What your thoughts?
I much prefer descriptive install file names. Sometimes, you want an emergency 'restore' disk to get a machine up and running even without internet connectivity. When all your installs are named "setup.exe", you either have to rename them all, or create a directory with a descriptive name for each one.
An example of where such a disk would have been really handy was when I took my brand new laptop in to work to use while I upgraded my desktop to Vista 64, and then Windows 7. I only have one wired LAN point, so my laptop needed a wireless connection for internet access, to download my installs. I had to download them all on my desktop, and then transfer by flash drive to my laptop. Very inconvenient.
Not sure this is entirely programming-related... but installer files are usually meant to be transient. You download them, run them, and delete them. (Or at least, I think most people do) So it doesn't matter much what the filename is.
I don't think there's any reason not to give the installer a descriptive name... but I certainly wouldn't say it "must" have one.
For CD-Rom based installation, I'd suggest sticking with SETUP.EXE which helps with autorun detecting software to install from the disk.
For downloadable files, just add the appropriate manifest to the EXE and Vista won't have a problem with it. I'd suggest something semi-descriptive, but there's no need to go into great detail unless it's something like hardware drivers that a person may archive off for reuse, otherwise the file name is confusing to non-technical people.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
In linux, if I have a file I'm sharing with a group, and I put the file on a USB memory stick, for example, and copy it to a computer that doesn't have the same group or users, does the file have no permissions for anyone on that new computer? What if I bring a linux file that only lets user X to read it to a windows machine? Who gets to read it on the windows machine? since user X (and group) doesn't exist on that machine.
What kind of security do I get copying a linux file to another linux machine? how about to a windows machine?
What kind of security do I get copying a windows file to another windows machine? how about to a linux machine?
Please let me know.
jbu
Regarding the USB key: generally, USB keys use one of the FAT family of filesystems; FAT doesn't support security at all, so as soon as you copy the file to it the security information is lost. So for your first question, anyone who has the USB key can read it on any computer from any user account. It is possible to format USB keys using another filesystem (for example, NTFS, which does support security); in that case, if the accounts (in Windows, at least, it must be a domain account or similar, just naming two accounts the same will not do it) do not exist on the target computer, only a user who can ignore filesystem permissions (such as root on *nix or Administrator on Windows) will be able to access the file.
For the second, I'm not 100% sure but I believe it depends on how you copy it; things like FTP and rcp generally don't copy permissions over, so I would assume that the file gets some kind of default permissions for the target directory, or a default built into the copy program, depending on what the copy program does.
For windows, to the best of my knowledge the security descriptor is initially inherited from the target folder; permissions are, again, not persisted across machines. It can be modified after the copy.
In general, except in specific environments that are designed to transfer permissions, I would assume that transferring any file from one computer to another resets the security permissions to a default (generally whatever a new file in that location would receive).
as technophile said, removable drives usually use FAT filesystems, so no permission info is copied at all.
on more 'direct' copies between *nix machines, if the writing process is run under root, usually there are flags to preserve permission bits and owner/group. also, most of them preserve user/group identities by the numbers. if there's no 'global' user identity database (LDAP, NIS, or even AD), be sure to look for a 'by name' identity.
some examples:
NFS: assumes 'identity by number', unless you use some 'squash' option to make every file the same owner/group.
cp: the '-p' flag preserves mode, ownership (by number) and timestamp.
scp: the '-p' flag preserves modes, but (usually) not ownership
rsync: only root can preserve ownership (-o,-g, or -p), tries to match usernames, but falls back to userids if not possible.
Why bother with permissions?
They get in the way most of the time unless you are running some sort of server.
Perhaps copy from linux FS to a FAT32, exfat, or NTFS FS so you don't have to deal with permissions?
That is what I do. I usually choose NTFS for file 'sharing' between desktop and laptop where laptop has linux and desktop has windows 7. Cannot easily do *nix laptop to *nix desktop without doing chmod multiple times (and even THAT doesn't guarantee R/W permissions)
When I tried to share between *nix's, everything was quite bad.
I need FULL read/write access by everyone on any box from any external drive.
Only problem with ntfs is if your *nix doesn't write to it or shut it down correctly.
Then I have to use windows to fix it (pain too). Hence one of the reasons I keep windows around.
Every flash and external drive I have are all NTFS except 2 of them which are fat 32 to 100% GUARANTEE no foul ups with linux demanding permissions (which many times I cannot change for some reason even with chmod).
Of course my data is plain old movies music pictures, similar domestic items.
But the same theory holds that if you don't or can't write permissions with the file, anyone should be able to use the file from any operating system.
I have gone so far as to copy a stubborn file onto a fat 32 flash drive just to strip permissions then copy it back. HATE typing command line stuff.
For me I need 100% read, write access to ANY data I have on external drives for all computers.
About using root - most linux 'suppliers' strongly discourage the use of root for doing many things.
Again, easy way around permissions is if you can copy it you can strip it by sending it to fat32. Or ntfs. And there goes the security.
If something is so sensitive that you NEED file security when file sharing then why share it in the first place?
If you want to prevent tampering with a file then burn it to a cd/dvd. That is read only. Even if they copy it and tamper with it the original is still untouched.